Данный документ подготовлен, чтобы помочь поставщикам услуг доступа к приложениям (ASP, Application service provider) в использовании платформы Microsoft® Exchange 2000 Server для разработки и хостинга приложений.

Услуги по хостингу приложений представляют собой право на удаленный доступ к приложениям, которое может приобрести заказчик, однако управление этими приложениями и их сопровождение осуществляется ASP-поставщиком. В сущности, заказчик передает ASP-поставщику свою информационную инфраструктуру полностью или частично. Сервер Exchange идеальным образом подходит в качестве платформы для хостинга приложений, поскольку системы передачи сообщений и совместной работы в силу своего широкого распространения принадлежат к числу стратегически важных приложений, хостинг которых может проводиться на коммерческой основе. Exchange 2000 построен на базе архитектуры сервера Exchange Server 5.5 и пакета Microsoft Commercial Internet System (MCIS) и служит платформой для размещения приложений ASP-поставщиком. Exchange 2000 обеспечивает масштабирование, поддерживает разделение сервисов, предоставляет средства разработки и широкий спектр возможностей для передачи сообщений и совместной работы.

В данном документе обсуждаются основные проблемы планирования и настройки, которые следует принимать во внимание при внедрении Exchange 2000 в качестве платформы для хостинга приложений на серверах ASP-поставщиков. В общих чертах рассматривается, как можно использовать Exchange 2000 в качестве платформы для хостинга приложений, и указываются источники более подробной информации. Настоящий документ адресован лицам, занимающимся проектированием архитектуры или управлением поставщика ASP. Здесь нет подробных описаний сценариев топологии и
API-интерфейсов, а также примеров расширения возможностей Exchange 2000. В дополнительном документе по этой теме Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков) по шагам расписана процедура развертывания и настройки системы Exchange 2000 для среды, в которой ASP-поставщик осуществляет хостинг приложений.

Для планирования, установки, настройки и сопровождения сервера Exchange 2000 требуются высококвалифицированные специалисты. Важную роль в проектировании, планировании и развертывании платформы коммерческих услуг может сыграть консультационная служба MCS (Microsoft Consulting Services), помогающая правильно воспользоваться богатыми возможностями систем Exchange и Microsoft Windows® 2000 Advanced Server.

Содержимое настоящего документа опирается на версию Exchange 2000 Release Candidate 1 (RC1), которая может не содержать все функции сервера. Кроме того, при работе с этой версией можно столкнуться с уже известными проблемами. Эти проблемы по мере возможности отмечены в данном информационном документе. Он будет обновлен, как только будет завершена работа над сервером Exchange 2000, или когда корпорация Майкрософт выпустит пакет обновления для системы Windows 2000.

Модели предоставления услуг asp и система Exchange 2000

Деятельность ASP-поставщиков привлекает все больше внимания: предлагаемые ими решения для сопровождения приложений опираются на широкое распространение технологий Интернета, помогающих бизнес-клиентам снижать свои производственные расходы.

Термин ASP (Application service provider – поставщик услуг доступа к приложениям) применяется для обозначения компаний-поставщиков, предоставляющих услуги доступа к установленным на их узлах приложениям. В целом модель ASP сводится к размещению бизнес-приложений на серверах ASP-поставщиков, обеспечивающему сокращение расходов и экономию, обусловленную ростом масштабов бизнеса.

Бизнес-модель ASP открывает благоприятные перспективы роста доходов для различных категорий производителей и поставщиков. Например, традиционные системные интеграторы смогут на базе модели ASP реализовать накопленный опыт в предоставлении профессиональных услуг и собственных решений. Взимая плату за размещение и сопровождение приложений, эти компании смогут получать прибыль в дополнение к доходам от самой разработки системы.

Новой областью деятельности является оказание услуг электронной почты и связанных с ней сервисов ASP-поставщиком. Службы передачи сообщений настраиваются согласно требованиям конкретного заказчика или предлагаются в единообразном виде, иногда дополняясь функциями рабочих групп (например, поддержкой совместного календаря и планирования), средствами совместной работы (такими, как служба Интернет-пейджинга и конференции в режиме реального времени), системой универсальной обработки сообщений и поддержкой беспроводной связи. Размещая у себя инфраструктуру и приложения систем передачи сообщений и совместной работы своих клиентов, ASP-поставщики позволяют им сосредоточить внимание не на технологии, а на сфере своей непосредственной деятельности.

Корпорация Майкрософт создавала сервер Exchange 2000 в расчете на модель хостинга приложений на серверах ASP-поставщиков. Сервер Exchange 2000 Server вобрал в себя все достоинства версии Exchange Server 5.5, позволяющие более полно удовлетворять запросы ASP-поставщиков. Используя среду Exchange 2000, ASP-поставщик сможет предложить клиенту новые функциональные возможности, которые позволят ему сэкономить его средства и повысить надежность работы. Благодаря повышению надежности и безопасности ASP-поставщики смогут гарантировать своим заказчикам более качественное обслуживание. Exchange 2000 позволяет ASP-поставщикам планомерно укрупнять свой бизнес, позволяя добавлять в систему новые хранилища, сервера и сервисы Новые средства управления, поддерживаемые Exchange 2000, позволят ASP-поставщикам снизить операционные расходы. В Exchange 2000 реализованы не только готовые службы, продукт представляет собой еще и платформу для разработки собственных сервисов, что позволит ASP-поставщикам дифференцировать свои предложения и расширить возможности для получения прибыли. Данный документ поможет спланировать организацию управления службами передачи сообщений и совместной работы.

Платформа Windows DNA с ее многоуровневой архитектурой является идеальной средой для хостинга Exchange 2000 Server. Эту универсальную, интегрированную платформу на базе системы Windows 2000 можно использовать для построения и развертывания бизнес-приложений в Интернете, начиная с веб-узлов электронной коммерции и кончая интегрированной сетью поставщиков предприятия, а также для быстрой разработки веб-приложений. Подробнее об архитектуре Windows DNA см. по адресу http://www.microsoft.com/dna. О том, как строить веб-узлы на платформе Windows DNA, можно прочитать по адресу http://msdn.microsoft.com/msdn-online/start/features/dnablueprint.asp.

Хостинг сервера EXCHANGE 2000 на платформе WINDOWS DNA

Разрабатывая архитектуру Windows DNA, корпорация Майкрософт ставила перед собой цель обеспечить следующие преимущества:

· масштабируемость;

· высокую отказоустойчивость;

· максимальную безопасность;

· управляемость.

В следующих разделах каждый из этих аспектов рассматривается более подробно.

Масштабируемость

Систему Exchange 2000 является масштабируемой, благодаря возможности разместить различные сервисы продукта на различных физических серверах. Затем сервера необходимо сконфигурировать оптимальным образом согласно выполняемому ими классу задач. Наконец для каждой группы задач можно добавить столько машин, сколько это необходимо для обслуживания нужного количества пользователей. Всего бывает три класска задач:

1. Совокупность серверов, работающих с протоколами, которые не поддерживают управление состоянием клиентов. Это внешние сервера, они переадресуют запросы внутренним серверам

2. Внутренние сервера оказывают основные виды услуг, на них работают сервисы хранилища и обработки сообщений.

3. Отдельные сервера предоставляют сервисы глобального каталога и служат контроллерами домена Active Directory. Службы каталога нужны для идентификации пользователя, управления доступом и хранилищем. Внешние сервера также используют глобальный каталог, чтобы определить какой именно внутренний сервер будет обрабатывать текущий внешний запрос.

На следующем рисунке показан пример развертывания Exchange 2000 в конфигурации с внешним и внутренним серверами.

Рис. 1. Система Exchange 2000 в конфигурации с внешним и внутренним серверами

Когда клиент подключается к серверу внешнему серверу, этот сервер запрашивает службу Windows 2000 Active Directory™ с целью проверки подлинности пользователя. Вместе с результатами проверки на внешний сервер передаются информация о местонахождении почтового ящика и общих папок. Как только учетные данные клиента признаны действительными, внешний сервер либо получает с внутреннего сервера содержимое почтового хранилища и передает клиенту изображение почтового ящика (включая структуру папок) по протоколу HTTP, либо организует обмен запросами между клиентом и хранилищем по протоколам POP3 (Post Office Protocol) или IMAP4 (Internet Message Access Protocol).

В конфигурации подобного типа внешние серверы должны уметь поддерживать связь со службой каталогов Active Directory с помощью удаленных вызовов процедур (Remote procedure call, RPC). Для получения уведомлений из службы Active Directory внешний сервер должен пройти регистрацию, используя те же средства RPC.

Примечание. Клиенты, поддерживающие MAPI, такие как Outlook® 2000, подключаются непосредственно к хранилищу и поддерживают связь при помощи стандартных механизмов, основанных на RPC-вызовах интерфейса MAPI. Подробнее об использовании приложения Outlook 2000 в качестве клиента см. ниже раздел «Клиенты».

Системы балансировки нагрузки, такие как NLBS (Network Load Balancing Services – службы балансировки сетевой нагрузки) или аппаратные решения, распределяют нагрузку по всем внешним серверам. В типичном центре данных рекомендуется установить, по крайней мере, два сервера в качестве контроллеров домена Windows 2000.

Высокая отказоустойчивость

Настройка узлов кластера NLBS обеспечивает высокие показатели отказоустойчивости внешних серверов системы и распределение нагрузки между ними. Повышению отказоустойчивости также способствуют средства обнаружения сбоев, встроенные в систему балансировки нагрузки. При отказе узла или его отключении служба NLBS автоматически перенастраивает кластер таким образом, чтобы клиентские запросы направлялись на оставшиеся компьютеры кластера. После выполнения необходимой профилактики компьютер, находившийся в автономном режиме, может прозрачно подключиться к кластеру и вновь принять на себя свою долю нагрузки.

Для получения более подробной информации о настройке службы NLBS обратитесь к электронной документации NLBS следующим образом.

1. Войдите на сервер внешнего интерфейса. На рабочем столе щелкните правой кнопкой мыши значок Мое сетевое окружение и выберите команду Свойства.

2. Щелкните правой кнопкой мыши сетевой адаптер службы NLBS и выберите команду Свойства.

3. Выберите элемент Балансировка нагрузки сети, нажмите кнопку Свойства и затем кнопку Справка.

Для повышения отказоустойчивости системы внутренних севреров можно воспользоваться кластеризацией с переключением при сбое. Кластеризация с переключением при сбое означает, что приложение может возобновить работу на другом компьютере, имеющем доступ к дисковой подсистеме узла, в котором произошел сбой. Переключение раздела при сбое имеет место, когда в главном узле, обслуживающем запросы к некоторому разделу, происходит сбой, и запросы к этому разделу автоматически переключаются на вспомогательный узел. Чтобы переключение производилось нормально, вспомогательный узел должен иметь доступ к тому же хранилищу данных, что и узел, в котором произошел сбой. Следует также выполнить репликацию этого хранилища. Наличие реплики повышает отказоустойчивость системы, если она расположена в другом месте. Для создания реплик хранилища данных применяются программные средства управления сетью хранилища (storage area network, SAM), выпускаемые независимыми производителями. Подробнее о принципах переключения при сбое см. информационный документ Introducing Windows 2000 Clustering (Знакомство с понятием кластеризации в системе Windows 2000) по адресу http://www.microsoft.com/WINDOWS2000/library/howitworks/cluster/introcluster.asp.

Внешние сервера выступают по отношению к внутренним в роли протокольных прокси-серверов, обеспечивая надежную и масштабируемую архитектуру. В то время как внешним серверам не нужна информация о состоянии соединения, внутренние серверы Exchange организуют сессии соединений, поэтому вы должны убедиться, что внутренние серверы обладают ресурсами быстродействия процессора и дисковой подсистемы, достаточными для быстрого и высоконадежного доступа к хранилищу. Эти внутренние серверы должны представлять собой крупные многопроцессорные компьютеры, соединенные друг с другом с помощью высокоскоростных подключений и изолированные от Интернета и прочих общедоступных сетей. Для обеспечения высокой отказоустойчивости эти серверы следует развертывать в кластеризованной среде, используя структуру из двух активных узлов с общим дисковым запоминающим устройством. Если какой-либо сервер перестанет работать, средства переключения при сбое автоматически передадут его долю нагрузки другому серверу, сохраняя непрерывность обслуживания. Сервер Windows 2000 Advanced Server поддерживает двух-узловую кластеризацию совместно с сервером Exchange 2000. Подробнее о поддержании целостности баз данных в случае переключения при сбое говорится в дополнительном документе по этой теме Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков).

Описанная выше многоуровневая архитектура, объединющая внешние и внутренние серверы, также помогает решать следующие проблемы повышенной нагрузки.

v Накладные расходы, связанные с протоколом SSL. Протокол SSL (Secure Sockets Layer) можно использовать для подключения клиента к внешнему серверу. В результате устанавливается защищенный канал для передачи сообщений, и при этом не требуется, чтобы этот интенсивно расходующий ресурсы центрального процессора протокол поддерживался и внутренними серверами.

v Медленные подключения. Модемное подключение увеличивает расход серверных ресурсов, поскольку сервер должен буферизовать данные, управлять потоком, сопровождать большее число подключений. Внешний сервер выступает в качестве шлюза между клиентом и сервисом доступа к хранилищу, снимая с хранилища нагрузку, порождаемую клиентским сеансом.

v Общие подключения. Внешние серверы мультиплексируют клиентские подключения, объединяя их в процессе взаимодействия с внутренними серверами. Это позволяет исключить накладные расходы, связанные с установкой и разрывом подключений между внешними и внутренними серверами. Кроме того, снижается нагрузка на внутренние серверы, поскольку им приходится поддерживать меньше подключений.

Интегрированная безопасность

Распределенная многоуровневая архитектура обеспечивает безопасность в трех главных доменах, каждый из которых защищен брандмауэром: это общедоступная сеть, зона DMZ (Demilitarized zone – демилитаризованная зона), в которой внешние серверы и информационные серверы ограждены брандмауэрами и фильтрами пакетов, и внутренняя сеть, в которой происходит создание или хранение информационных материалов, а также администрирование и хранение защищенных данных. В целях укрепления безопасности можно создать несколько доменов с разными уровнями безопасности и разместить в них системы, обладающие различными требованиями к обеспечению безопасности, защитив каждый домен сетевым фильтром или брандмауэром. Брандмауэр следует настроить так, чтобы он блокировал все порты, за исключением тех, которые нужны именно для данного типа предоставляемых услуг. К этим портам относятся следующие:

· протокол SMTP, порт 25;

· протокол POP3, порт 110;

· протокол IMAP4, порт 143;

· служба DNS (Domain name service – служба доменных имен), порт 53;

· протокол HTTP, порт 80;

· HTTP по SSL (HTTPS), порт 443.

Полный перечень протоколов и соответствующих им портов см. в документе ftp://ftp.microsoft.com/services/isn/ops/security/ipfilters.doc.

Управляемость

Простота администрирования, легкость настройки, возможности постоянного наблюдения и обнаружения сбоев – все это имеет большое значение для управления веб-узлами, построенными на базе архитектуры Windows DNA. Нередко ASP-поставщикам приходится управлять своими веб-узлами, созданными на платформе Windows DNA, в удаленном режиме. Если вы занимаетесь хостингом Exchange 2000, то для решения задач управления можете воспользоваться консолью управления MMC (Microsoft Management Console) и прилагающимися к ней модулями.

Конфигурация с внешними и внутренними серверами обладает высокими показателями масштабируемости. Если ваша организация небольших размеров, вы можете установить подобную систему всего лишь с шестью серверами: тремя внешними, которые обслуживают разные протоколы (POP3, IMAP4, SMTP) и Outlook Web Access, и тремя внутренними серверами, с размещенными на них сервером Exchange 2000, службой Active Directory и глобальным каталогом.

Если ваша организация обслуживает несколько крупных компаний с тысячами пользователей, то при внедрении системы можно применить тот же подход, добавив в конфигурацию требуемое количество внешних и внутренних серверов. Система внешних серверов может включать выделенные серверы для каждого протокола, а также серверы для входящего и исходящего трафика по протоколу SMTP. Система внутренних серверов может включать полномасштабные серверы для Exchange 2000, службы Active Directory и глобального каталога, каждый из которых оборудован восемью процессорами и обладает четырьмя гигабайтами памяти. Внутренние серверы можно объединить в кластеры, состоящие из двух узлов, организовав совместное использование дискового пространства для SAN-решения (SAN – Storage Area Network). На следующем рисунке показана топология развертывания Exchange 2000 в организации больших размеров.

Рис. 2. Система Exchange 2000 в крупномасштабной среде

В документе Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков) приводится пример настройки Exchange 2000 для проведения размещения. Этот документ можно найти на www.microsoft.com/isn/ .

Windows 2000 и Exchange 2000

Сервер Exchange 2000 Server полностью интегрирован c сервером Windows 2000 Advanced Server, что позволяет пользоваться всеми возможностями последнего. В частности, сервер Windows 2000 Advanced Server поддерживает службу Active Directory, средства кластеризации и переключения при сбое, а также консоль управления MMC. В данном разделе рассказывается, как можно использовать службу Active Directory для реализации функций управления, обеспечения безопасности и масштабирования, что весьма актуально при хостинге Exchange 2000.

Как в Exchange 2000 используется служба каталогов Active Directory

Active Directory – основополагающая служба системы Windows 2000, формирующая логическое представление информации в сети; она организована в виде иерархии деревьев, образующих лес. Служба Active Directory хранит данные о сетевых объектах так, что пользователи и администраторы могут без труда находить эту информацию и управлять ею. Объекты службы Active Directory представляют отдельных пользователей, группы, приложения и ресурсы, и этими объектами можно централизованно управлять в рамках структуры Active Directory.

В Exchange 2000 служба Active Directory используется для просмотра объектов, обеспечения безопасности и разрешения имен. Со службой Active Directory тесно интегрированы групповые политики, операции поиска в адресной книге, средства проверки подлинности пользователей, хранилища почты.

При развертывании Exchange 2000 в службе Active Directory хранятся глобальные списки адресов, таблицы управления доступом (ACL – Access Control Lists), списки автономных адресов и политики получателей – правила электронной почты Exchange, сопоставляемые пользователям и группам в службе Active Directory. Кроме того, служба Active Directory является центральным пунктом администрирования при использовании политик безопасности Exchange. Такая централизованная конструкция позволяет делегировать административные полномочия каждому заказчику в отдельности.

Службы централизованного управления

Служба Active Directory играет роль центрального пункта администрирования при хостинге Exchange 2000 и других приложений в среде сервера Windows 2000 Advanced Server. Структура службы Active Directory с несколькими главными контроллерами домена удобна и для поставщиков услуг доступа к одному центру данных, и для обслуживания нескольких распределенных центров данных, – она предоставляет единое масштабируемое хранилище для данных о конфигурации приложений, информации, связанной с проверкой подлинности пользователей, сведений о службах, организации иерархических структур. Наличие такого единого хранилища существенно упрощает процесс управления для компаний, предоставляющих бизнес-услуги передачи сообщений и совместной работы тысячам клиентов. Служба Active Directory протестирована на практике в процессе обслуживания нескольких миллионов пользователей и допускает расширение охвата в соответствии с потребностями ASP-поставщиков.

Служба Active Directory базируется на структуре леса, которая может поддерживать тысячи доменов. Корень леса разбивается на разделы, в которых размещается информация, относящаяся к различным компаниям. Чтобы обеспечить защиту данных, следует установить, по крайней мере, два контроллера домена (основной и резервный) и, по крайней мере, два сервера глобальных каталогов. Контроллер домена – это сервер, работающий под управлением системы Windows 2000, поддерживающий раздел службы Active Directory; глобальные каталоги содержат частичную реплику всех доменов Windows 2000, включенных в каталог, и позволяют приложениям и пользователям быстро находить объекты в службе Active Directory. В Exchange используются серверы глобальных каталогов для проверки подлинности пользователей при доступе к различным службам Exchange. Когда вы установите первый сервер Active Directory в структуре леса, система Windows 2000 автоматически настроит его в качестве сервера глобального каталога.

Каждому клиенту ASP-поставщика отводится одно подразделение в службе Active Directory. Подразделение – это логический контейнер в структуре организации, который может вмещать другие объекты, например, пользователей, группы, параметры безопасности, правила Exchange и прочую информацию, относящуюся к данной компании. Формируя подразделения, вы можете делегировать административные права отдельным поддеревьям каталога. На следующем рисунке показан пример иерархии подразделений (OU).

Рис. 3. Иерархия подразделений

Если в один лес включены несколько организаций с различными доменными именами, то для того, чтобы у сотрудников вашего клиента были простые пользовательские имена для входа в систему и адреса электронной почты, вы можете воспользоваться системой имен UPN (User Principal Name – основное имя пользователя).

Механизм имен UPN дает возможность пользователю войти в систему под именем user1@CompanyA: ему не придется указывать полное имя, включающее название вашей компании, например, user1@CompanyA.MyHosting.com. Такой метод гораздо удобнее для пользователя и снижает число ошибок, допускаемых при вводе имен. При использовании имен UPN все запросы на проверку подлинности автоматически перенаправляются в подразделение пользователя – именно в то, в которое он имеет право входить.

Использование имен UPN избавляет от конфликтов между пространствами имен, которые могут возникать, если вы, например, обслуживаете пользователей bob@CompanyA и bob@CompanyB. Поскольку в формате UPN для различения пользователей применяются имя домена и идентификатор пользователя, каждому домену разрешается иметь свое собственное пространство имен.

Внутри подразделений можно создавать более мелкие подразделения, представляющие группы сотрудников организации; например, в главном подразделении CompanyA.com можно выделить вспомогательное подразделение marketing (отдел маркетинга) и еще один отдел sales (сбыт). Подробнее о том, как создать подразделение и установить для него соответствующую политику безопасности говорится в дополнительном документе по этой теме Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков).

Вы можете создать подразделение верхнего уровня и затем отдельные дочерние подразделения, соответственно для вашей собственной компании и для организаций, которые вы обслуживаете. Таким образом вы сможете предоставить пользователям этих организаций ограниченный набор разрешений независимо от полномочий, которыми обладают пользователи вашей компании.

Глобальный каталог

Глобальный каталог создается автоматически при установке службы Active Directory на контроллере домена. Глобальный каталог содержит частичную реплику всех доменов Windows 2000, включенных в каталог системы, и дает возможность пользователям и приложениям отыскивать объекты в дереве доменов Active Directory по одному или нескольким атрибутам. Он также содержит схему и конфигурацию разделов системного каталога. Это означает, что в глобальном каталоге хранится реплика каждого объекта Active Directory. Глобальный каталог – это LDAP-совместимый (Lightweight Directory Access Protocol) раздел каталога системы, оптимизированный для просмотра адресной книги. В Exchange 2000 глобальный каталог содержит глобальный список адресов – адресную книгу, в которую внесены все пользователи организации.

В глобальном каталоге также хранится полная реплика всех объектов домена, которому он принадлежит, и частичная реплика объектов других доменов. Глобальный каталог выполняет следующие две основные функции.

· Он обеспечивает вход в сеть, предъявляя контроллеру домена информацию о членстве в универсальной группе, когда пользователь инициирует процесс входа. Пользователю не нужно прикрепляться к конкретному серверу глобального каталога, благодаря чему обеспечивается высокая надежность и простота процесса проверки подлинности.

· Глобальный каталог позволяет пользователям и приложениям отыскивать нужную информацию независимо от того, в каком домене леса она содержится.

Когда пользователь входит в сеть, глобальный каталог передает контроллеру домена информацию о том, принадлежит ли универсальной группе учетная запись, выдавшая запрос на вход. Если в домене Windows имеется только один контроллер, он выполняет также функции сервера глобального каталога. Если в лес входит несколько доменов Windows, каждый из них будет иметь свой собственный контроллер, но при этом вы должны также установить, по крайней мере, один сервер глобального каталога для каждого домена. Если в момент инициирования пользователем процесса входа в сеть глобальный каталог недоступен, пользователь сможет войти только в среду своего локального компьютера.

Глобальный каталог реагирует на обращения пользователей и программ, запрашивающих объекты в различных частях леса, с максимальной скоростью, порождая минимальный сетевой трафик. Поскольку в одном глобальном каталоге содержится информация об объектах всех доменов леса, запрос объекта может быть разрешен глобальным каталогом в том домене, в котором был выдан запрос. Тем самым поиск информации в системном каталоге не генерирует ненужный междоменный трафик.

Подробнее о планировании развертывания службы Active Directory см. документ Deployment Planning Guide (Руководство по планированию развертывания), входящий в комплект материалов Windows 2000 Server Resource Kit.

Безопасность

Безопасность представляет собой важный аспект функционирования каталога, и при планировании развертывания системы Exchange вам следует тщательно рассмотреть все вопросы, связанные с безопасностью. При развертывании ASP-поставщиком сервера Exchange 2000 Server, в системе безопасности выделяются следующие два элемента:

· проверка подлинности при входе в систему – согласованная политика в отношении пользовательских имен и паролей, обеспечивающая пользователям доступ к службам Exchange;

· безопасность каталога – метод управления правами доступа конкретных пользователей к сетевым ресурсам.

В следующих разделах описываются механизмы систем Exchange 2000 и Windows 2000, используемые для формирования стратегии безопасности.

Проверка подлинности при входе в систему

Если Exchange 2000 развертывается вместе с системой Windows 2000, можно выбрать один из четырех типов проверки подлинности при входе, в зависимости от требуемого уровня безопасности. Эти режимы проверки перечислены ниже в порядке возрастания строгости критериев проверки.

· Анонимный доступ. Этот режим целесообразно применять в отношении общедоступной информации, если вы хотите, чтобы пользователи могли получать ее, не указывая свое имя и пароль. Однако службы IIS (Internet Information Services) 5.0 требуют, чтобы доступ к подобной информации осуществлялся при помощи учетной записи пользователя, для чего во время процесса установки создается специальная учетная запись вида IUSR_имя_компьютера.

· Обычная (текстовая) проверка подлинности. Этот режим требует, чтобы пользователь, желающий получить доступ к веб-узлу, указал свое имя и пароль. Учетные данные пользователя передаются через Интернет открытым текстом. Обычная проверка подлинности поддерживается всеми обозревателями, но поскольку обычный текст легко перехватывается, этот метод не обеспечивает достаточную безопасность. Для использования данного типа проверки подлинности пользователя необходимо в службе IIS предоставить учетной записи IUSR_имя_компьютера права на локальный вход.

· Обычная проверка подлинности по протоколу SSL. Данный метод действует точно так же, как и предыдущий, только учетные данные пользователя перед передачей на сервер шифруются по протоколу SSL (Secure Sockets Layer), что повышает уровень безопасности. Поскольку шифрование по протоколу SSL повышает нагрузку на сервер, к которому подключен клиент, использование этого метода может привести к снижению быстродействия сервера.

· Встроенная проверка подлинности средствами Windows. Эта процедура (старое название – проверка NTLM Challenge/Response) выполняется так: сначала обозреватель пытается войти в систему из домена входа, предъявляя учетные данные текущего пользователя. Если эти учетные данные отвергаются, у пользователя запрашиваются его имя и пароль, но при этом пароль не передается по сети. Такой метод более безопасен, чем обычная проверка подлинности, но его нельзя применять, если пользовательским учетным данным предстоит проходить через брандмауэр.
Интегрированная проверка подлинности средствами Windows использует протокол Kerberos V5, который принимается по умолчанию в качестве метода сетевой проверки подлинности на компьютерах, работающих под управлением системы Windows 2000. Чтобы получить билет службы Kerberos V5 для проверки подлинности на сервере, клиент должен сначала обратиться в центр распространения ключей (Key Distribution Center, KDC), обслуживающий домен этого сервера (обычно его роль играет контроллер домена). Поскольку клиент должен обращаться в службу KDC напрямую, протокол Kerberos V5 лучше подходит для интрасетей, чем для Интернета. Исключением может оказаться клиент, использующий протокол PPTP (Point-to-Point Tunneling Protocol) для подключения к виртуальной частной сети (Virtual private network, VPN). Подробнее о клиентах, которые могут использоваться при формировании сети VPN, см. ниже раздел «Клиенты».

Помимо этого, в службе IIS для связи по протоколу HTTP можно использовать проверку подлинности в режиме выборки. Данный метод аналогичен обычной проверке подлинности, только пароли перед отправкой на сервер шифруются. Пользователи, работающие с обозревателями, поддерживающими проверку подлинности в режиме выборки, удостоверяют свою подлинность на сервере IIS, не подвергая свои учетные данные риску.

Безопасность каталога

При помощи средств безопасности каталога определяется, что именно может видеть в каталоге отдельный пользователь. Пользователи всех обслуживаемых компаний размещаются в одном и том же экземпляре службы Active Directory, поэтому важно аккуратно построить структуру каталога, так чтобы она обеспечивала надлежащие разрешения каждой группе пользователей. Если система безопасности настроена правильно, пользователям будет доступна только информация, относящаяся к их компании.

Ниже на схеме показано, как действует этот метод.

Рис. 4. Безопасность каталога

Для определения уровня доступа пользователей к сетевым ресурсам служба Active Directory использует следующие механизмы.

· Таблицы управления доступом (ACL – Access Control Lists) – списки разрешений, в которых указано, какие пользователи могут получать доступ к объектам службы Active Directory.

· Записи управления доступом (ACE – Access Control Entries) – записи, определяющие вид разрешения (например, «Чтение», «Запись», «Выполнение» и т.д.).

· Политики безопасности – политики, определяющие функциональный диапазон службы безопасности системы. Используя объекты групповой политики в службе Active Directory, администраторы могут централизованно применять необходимые профили безопасности к различным организациям, представленным в каталоге.

Подробнее о том, как настраивать разрешения службы Active Directory для просмотра каталога по подразделениям говорится в документе Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков).

Безопасность каталога также подразумевает определенный порядок предоставления разрешений администраторам ваших клиентов. Администратору должно быть разрешено контролировать только ту часть сведений службы Active Directory, которая относится к его организации, но не весь каталог. Администраторы обслуживаемых организаций, отвечающие за сопровождение почтовых ящиков и пользователей и за доступ к конкретным службам, должны использовать специальное средство администрирования, которое позволит им управлять пользователями своих организаций, но не даст разрешений на управление другими частями службы Active Directory. Порядок предоставления разрешений описывается в одном из следующих разделов документа.

В состав Exchange 2000 входит мастер делегирования разрешений, с помощью которого можно назначать или делегировать административные права пользователям или группам, зарегистрированным в службе Active Directory. После выполнения действий, предписываемых мастером, вам предлагается на выбор несколько вариантов установки прав на администрирование. Вы можете создать собственную оснастку для консоли MMC, открывающую доступ только к части службы Active Directory. Можно также построить специальное средство с помощью системы разработки Visual Studio®, используя интерфейсы ADSI (Active Directory Service Interfaces – интерфейсы службы Active Directory) и CDOEXM (Collaboration Data Objects for Exchange Management – объекты данных совместной работы для управления средой Exchange). Подробнее консоль MMC и интерфейсы ADSI и CDOEXM описываются в последующих разделах.

Примечание. Мастер делегирования разрешений позволяет делегировать управление конфигурацией серверов Exchange. Однако он не позволяет полностью делегировать контроль над конфигурацией пользователей администраторам ваших клиентов, которые управляют не серверами, а пользователями.

Подробнее о безопасности см. веб-страницы http://www.microsoft.com/security и http://www.microsoft.com/exchange/55/whpprs/Security2000.htm.

Клиенты

Для доступа к службам Exchange могут использоваться следующие клиенты.

· Outlook Express. Это приложение можно настраивать на доступ по протоколу POP3 или IMAP4 к серверам Exchange; однако для этих протоколов приложение Outlook Express использует обычную проверку подлинности. Чтобы установить более безопасное подключение, можно с помощью Outlook Express настроить виртуальную частную сеть VPN. В сети VPN приложение Outlook Express можно настроить на использование алгоритма SPA (Secure Password Authentication), который рассчитан на применение совместно с проверкой NTLM.

· Outlook Web Access. Эту программу можно настроить на доступ к службам Exchange по протоколам HTTP и HTTPS. Программа Outlook Web Access по умолчанию использует обычную проверку подлинности; если требуется более безопасное подключение, можно задать обычную проверку подлинности по протоколу SSL.

· Outlook 2000. Данное приложение можно настроить в качестве клиента Интернета или клиента MAPI.

· Если приложение Outlook 2000 настроено как клиент Интернета, оно использует протокол POP3 или IMAP4 и обычную проверку подлинности.

· Чтобы настроить приложение Outlook 2000 в качестве клиента MAPI, достаточно установить сеть VPN. Интерфейс MAPI использует для связи удаленные вызовы процедур (RPC), которые действуют только в рамкаходной рабочей группы или при подключении по VPN. Поскольку в сетях VPN используется выделенное подключение, проходящее через брандмауэр, можно применить встроенную проверку подлинности средствами Windows.

В следующей таблице перечислены клиенты и используемые протоколы, с указанием преимуществ и недостатков каждого клиента.

Клиент	Проверка подлинности	Протоколы	Преимущества	Недостатки
Outlook Web Access	Обычная, обычная по протоколу SSL, NTLM, выборка	HTTP, HTTPS	Обычная проверка не зависит от обозревателя, проста в обслуживании при хостинге, не зависит от клиента, не требует обновлений клиента, протокол SSL позволяет зашифровать весь сеанс	Не поддерживаются возможности автономной работы, для защиты подключений требуется протокол SSL, протокол SSL снижает быстродействие, для NTLM требуется сеть VPN, NTLM не действует в топологии с внешним и внутренним серверами
Outlook 2000	NTLM, обычная	MAPI, POP3, IMAP4	Богатые функциональные возможности, широкий спектр возможных пользователей	MAPI трудна в обслуживании при хостинге, клиенты MAPI подключаются только к внутренним серверам (где хранятся почтовые ящики), для клиента MAPI требуется сеть VPN, возрастает объем трафика
Outlook Express	Обычная, обычная по протоколу SSL, NTLM	POP3, IMAP4, LDAP	Широкий спектр возможных пользователей, низкие накладные расходы, хорошее быстродействие	SSL снижает быстродействие, для NTLM требуется сеть VPN
Клиенты POP3, IMAP4 общего типа	Обычная	POP3, IMAP4	Широкое распространение	Недостаточная функциональность

Масштабируемость и отказоустойчивость

Сервер Exchange 2000, работающий в среде Windows 2000 Advanced Server, может обслуживать свыше 1 миллиона пользователей и почтовых ящиков в стандартных моделях использования Интернета. Корпорация Майкрософт намерена продолжать тестирование систем Exchange 2000 и Windows 2000 Advanced Server на других моделях с увеличением числа пользователей и параллельно публиковать отчеты о масштабируемости и рекомендации по настройке оборудования.

Один сервер с Exchange 2000 может обслуживать десятки тысяч и более пользователей в зависимости от ожидаемой нагрузки, которая, в свою очередь, зависит от типа сообщений, числа одновременно работающих пользователей и количества доступных служб, например календаря, и планирования интервалов занятости. При этом предполагается, что Exchange работает на компьютере с восемью процессорами и оперативной памятью объемом от 2 до 4 ГБ.

Подробнее о планировании Active Directory см. описание служебной программы настройки масштабирования службы (sizing utility) Active Directory, входящей в комплект материалов Windows 2000 Server Resource Kit.

Необходимо подчеркнуть, что в конфигурацию следует включить более одного глобального каталога и контроллера домена. Если имеется только один контроллер домена, то в случае сбоя домен и информация службы Active Directory будут утеряны. Точно так же, если используется только один глобальный каталог и он будет поврежден, пользователи не смогут входить в сеть. Им удастся войти на локальный сервер, но только тем из них, у кого на этом сервере есть локальная учетная запись.

внедрение Exchange 2000

В данном разделе обсуждаются вопросы внедрения Exchange 2000, представляющие особый интерес для ASP-поставщиков, в том числе разделение ресурсов, настройка конфигурации и кластеризация.

Разделение ресурсов Exchange 2000

Первым этапом внедрения Exchange 2000 является разделение ресурсов. Это можно делать следующими способами.

v Один заказчик на организацию Exchange. В этом случае вы будете иметь отдельный лес AD и набор серверов для каждого заказчика. Такая конфигурация оптимальна, если вы предоставляете услуги для больших компаний.

v Один заказчик на сервер. В этом случае вы будете использовать один лес AD для нескольких заказчиков, каждый из которых будет обслуживаться одним или несколькими серверами Exchange. Данные заказчиков будут полностью разделены. Эта конфигурация оптимальна для обслуживания средних и крупных заказчиков.

v Один заказчик на хранилище. В этом случае данные заказчиков будут полностью разделены (поскольку каждое хранилище – это набор баз данных и журналов транзакций), но каждый сервер или двух-узловой кластер сможет обслуживать до четырех заказчиков. Такая конфигурация применяется для обслуживания средних по размеру организаций.

v Один заказчик на базу данных. В этом случае на одном сервере может обслуживаться до 20 организаций, разделение данных которых будет осуществляться на уровне баз данных. Необходимо отметить, что в этом случае все базы данных в хранилище будут иметь общие журналы транзакций. Этот сценарий подходит для небольших и средних организаций.

v Несколько заказчиков на базу данных. Эта модель потенциально наиболее масштабируема, поскольку позволяет обслуживать на одном сервере сотни организаций. Данные всех заказчиков будут при этом храниться в одной базе. Этот сценарий подходит для обслуживания малых организаций и дает минимум гибкости в организации разных уровней сервиса.

Разделяя ресурсы Exchange 2000, не забывайте о соглашении SLA, которое вы заключили со своими заказчиками, и следите за размерами хранилищ: они должны быть такими, чтобы вы могли восстановить базу данных после возможного сбоя за приемлемое время. Это требование накладывает также ограничение на число пользователей, обслуживаемых на одном сервере Exchange, потому что один сервер может вмещать до четырех групп хранилищ, каждая из которых содержит до пяти баз данных сообщений.

Использование нескольких баз данных для одного заказчика позволяет выделить больше пространства для групп хранилищ. Поскольку данные распределены по нескольким базам данных, вы можете формировать более крупные группы хранилищ. И вновь размер каждой группы определяется в соответствии с соглашением SLA, заключенным с каждым из заказчиков.

Приведенная схема иллюстрирует два способа настройки групп хранилищ.

Рис. 5. Примеры конфигурации группы хранения

Примечание. Заказчикам, подписавшим одинаковые соглашения SLA, целесообразно выделить набор групп хранилищ с одной и той же политикой архивации и восстановления. Для организаций, использующих общую базу данных, можно установить разные политики, однако в этом случае управлять ими станет труднее. Если различные соглашения SLA требуют разных политик архивации и восстановления, то для упрощения администрирования следует разместить каждую из таких компаний в отдельном кластере.

Настройка административных групп

Административная группа – это группа серверов, на которых работает Exchange и которыми можно управлять как одной логической единицей. Конфигурация административной группы запоминается в контексте именования службы Active Directory, что позволяет реплицировать конфигурацию в рамках всей организации. Административная группа может включать любое число политик, групп маршрутизации, деревьев общих папок, серверов, служб конференций и сетей разговоров.

Используя административные группы, вы можете объединять административные объекты для удобства навигации и управления. Вы можете не отображать административные группы в пользовательском интерфейсе при обслуживании компаний небольшого размера, когда эти возможности не нужны.

Примечание. В сценарии хостинга приложений не следует создавать более одной административной группы, хотя это и может показаться необходимым при работе с большим массивом серверов, обеспечивающим различные уровни обслуживания для разных компаний. Администраторы ASP-поставщика управляют серверами Exchange, а администраторы обслуживаемых компаний выполняют свои задачи по управления пользователями путем делегирования полномочий.

Настройка групп маршрутизации

Группы маршрутизации – это группы серверов, связанных между собой надежными, высокоскоростными, постоянными подключениями. Каждый сервер Exchange, входящий в группу маршрутизации, может непосредственно контактировать с любым другим сервером, так что сообщения доставляются с сервера на сервер за один сеанс.

Если постоянные, надежные подключения установлены только в одной группе серверов Exchange, значит, вы сможете воспользоваться только одной группой маршрутизации. Тем не менее, это предполагает соблюдение следующих условий:

v серверы Exchange принадлежат одному и тому же экземпляру службы Active Directory;

v между серверами Exchange существует постоянное подключение SMTP;

v все серверы Exchange могут связываться с главным сервером маршрутизации.

Вы можете развернуть несколько групп маршрутизации, если определены границы доменов компаний.

На приведенной иллюстрации показывается представление административной группы и группы маршрутизации на консоли управления MMC.

Рис. 6. Административная группа и группа маршрутизации на консоли MMC

Использование кластеризации

Серверы Exchange 2000 Server и Windows 2000 Advanced Server поддерживают режим симметричной кластеризации. Кластер состоит из двух или более компьютеров (узлов), подключенных друг к другу и к общему запоминающему устройству. В кластере создается один или несколько виртуальных серверов Exchange, каждый из которых функционирует в одном из узлов кластера. Exchange 2000 может поддерживать несколько виртуальных серверов в одном узле. Клиенты подключаются к виртуальным серверам точно так же, как к автономному серверу.

Средства кластеризации Exchange обеспечивают высокую отказоустойчивость системы передачи сообщений. Служба кластеров следит за работой виртуальных серверов в составе кластера и в случае сбоя какого-либо виртуального сервера перезагружает его или перемещает на работоспособный узел. Во время плановых простоев вы можете вручную переносить виртуальные серверы в другие узлы. И в том, и в другом случае обслуживание заказчика ненадолго прервется – на время, требующееся для его перезапуска. Использование нескольких серверов сокращает системные расходы и одновременно повышает надежность, так как отпадает необходимость в выделенных серверах, используемых в качестве резерва на случай переключения при сбое.

Настройка переключения при сбое

Переключение при сбое бывает двух видов – плановое и внеплановое.

Плановые переключения, например, для проведения профилактики, следует назначать на нерабочее время. В случае планового переключения буферы модуля ESE (Extensible Storage Engine) сбрасываются в базы данных, группы хранилищ отключаются и происходит переключение управления. Затем группы хранения подключаются к другому серверу, и запускаются соответствующие серверы протоколов.

Если на сервере происходит аварийный сбой, активизируются группы хранилищ, повторяются транзакции из файлов журналов, начиная с контрольной точки, и запускаются соответствующие серверы протоколов. В результате продолжительность времени переключения при аварийном сбое зависит от размера общих файлов журналов. Базы данных остаются недоступными до тех пор, пока не закончится повторение транзакций всех файлов журналов. Об этом следует помнить при построении баз данных и групп хранилищ.

Настройка иерархий общих папок

Сервер Exchange 2000 Server использует поддержку нескольких баз данных для поддержки возможности создания нескольких иерархий общих папок, или иерархий верхнего уровня (TLH). Каждая иерархия реплицируется только в одно хранилище общих папок для каждого сервера. Это означает, что достаточно иметь набор общих папок отдела только на одном сервере: так удобнее осуществлять административный контроль. Кроме того, данные можно реплицировать на другие серверы.

Для получения доступа к общим папкам пользователи подключаются к почтовому ящику в личном хранилище, которому по умолчанию сопоставлено хранилище общих папок, связанное с некоторым деревом общих папок через механизм репликации. По умолчанию пользователи видят только дерево, с которым связано их хранилище общих папок.

Общие папки настраиваются точно так же, как и другие элементы Exchange 2000. Каждая обслуживаемая организация (подразделение) должна видеть только один корень общих папок. Для этого вам следует создать наборы общих папок одного уровня – по одному набору для каждой организации. Таким образом каждая организация сможет видеть только свои собственные общие папки, но не папки других организаций.

После того, как настройка параметров безопасности закончится, пользователи каждого подразделения будут видеть только общие папки, на которые у них имеются соответствующие разрешения.

Управление сервером Exchange

В данном разделе описываются средства, используемые для управления средой Exchange, и перечисляются типы инструментальных средств, которые вы можете создавать сами.

Консоль управления MMC

На консоли управления MMC отображены административные средства, имеющиеся в стандартном пользовательском интерфейсе, а также содержатся модули оснастки, которые можно использовать для управления сетями, компьютерами, службами и другими системными компонентами. Консоль MMC устанавливается по умолчанию вместе с системой Windows 2000 Server, и с ее помощью можно администрировать многие приложения, включая сервер Exchange 2000 Server. Используя консоль MMC, можно создавать, сохранять и открывать наборы административных средств, называемые консолями. Эти консоли могут содержать такие элементы, как модули оснастки, оснастки расширений, элементы управления, задачи и мастера, а также ссылки на документацию, которую можно использовать для справки при управлении аппаратными, программными и сетевыми компонентами системы.

Администрирование сервера Exchange 2000 Server осуществляется с помощью различных модулей оснастки MMC, содержащих наборы инструментов управления сетевыми ресурсами и сообщениями. Консоль MMC можно индивидуально настраивать для администраторов, исполняющих конкретные роли; например, можно разрешить администратору системы передачи сообщений просматривать административное представление учетных записей пользователей или разрешить системному архитектору просматривать все свойства серверов Exchange. Подробнее о консолях MMC см. документацию по системе Windows 2000 Server.

Оснастка System Manager

Оснастка System Manager (Диспетчер системы) позволяет управлять всеми аспектами работы сервера Exchange 2000 Server через общий интерфейс. System Manager также дает возможность организовать административные объекты таким образом, чтобы было легче перемещаться между ними и устанавливать разрешения на доступ к ним. Оснастка System Manager – это сохраненный файл консоли, который можно запускать из меню Пуск после установки сервера Exchange.

System Manager подключается к контроллеру домена для получения сведений о соответствующей конфигурации и пополнения набора оснасток. В определенных ситуациях бывает необходимо направить модули оснасток в конкретную часть домена или на конкретный контроллер домена. Если вы хотите регулировать либо вообще исключить задержку, связанную с репликацией информации службы Active Directory, подключиться к некоторому домену леса Windows 2000 или подключиться к различным контроллерам доменов в различных лесах Windows 2000 для управления различными компаниями или отделениями, вам придется перенаправлять эти модули оснасток.

Создание собственных инструментов

Вы можете не только пользоваться стандартными модулями, такими как оснастки System Manager или «Active Directory – пользователи и компьютеры», но и создавать свои собственные приложения с помощью средств Visual Basic®, Visual Basic Scripting Edition (VBScript), Visual C++® и Visual InterDev®. Эти служебные программы взаимодействуют с операционной системой, службой Active Directory и серверами Exchange посредством интерфейсов ADSI (Active Directory Services Interface – интерфейс службы Active Directory), WMI (Windows Management Instrumentation – инструментарий управления Windows), CDO для Windows 2000 (Collaboration Data Objects – объекты для совместной работы), CDOEX (CDO для Exchange Server) и CDOEXM (CDO для управления Exchange). В следующих разделах приводится обзор этих интерфейсов.

Интерфейс ADSI

Чтобы вы имели доступ к службе Active Directory на более глубоком уровне, чем позволяют стандартные средства консоли MMC, корпорация Майкрософт разработала интерфейс ADSI (Active Directory Service Interface – интерфейс службы Active Directory). Интерфейс ADSI – это собрание COM-интерфейсов, которые дают вам возможность строить свои собственные приложения, сценарии и страницы Active Server Pages для управления службой Active Directory.

Объекты ADSI представляют собой COM-объекты, соответствующие постоянным объектам службы каталогов. Операции с объектом ADSI осуществляются с помощью одного или нескольких COM-интерфейсов. Объекты ADSI разделяются на две группы: оконечные листовые объекты службы каталогов и контейнеры службы каталогов. Различаются они тем, что контейнер может содержать другие объекты ADSI, а оконечный листовой объект не может.

ADSI-провайдер содержит экземляты объектов ADSI и зависимых объектов для конкретного пространства имен. На следующей схеме показано, как клиент поддерживает связь со службой Active Directory через ADSI-провайдера.

Рис. 7. Использование интерфейса ADSI для связи клиента с каталогом Active Directory

Используя вместе с интерфейсом ADSI средства Visual Basic, VBScript, JavaScript, C, C++, Windows Scripting Host, Visual C++ и Active Server Pages, можно создавать и изменять объекты любого вида в каталоге.

В документе Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков) содержатся примеры применения языков VBScript и Visual Basic в комбинации с интерфейсом ADSI. Подробнее об интерфейсе ADSI см. раздел «ADSI» в документации комплекта Microsoft Platform SDK.

Интерфейс WMI

Чтобы сделать системы Windows 2000 и Exchange 2000 более управляемыми, корпорация Майкрософт разработала технологию WMI (Windows Management Instrumentation – инструментарий управления Windows). Интерфейс WMI создан на основе проекта WBEM (Web-Based Enterprise Management – управление предприятием при помощи веб-технологий) группы DMTF (Distributed Management Task Force – рабочая группа по распределенному управлению); он расширяет модель CIM (Common Information Model – общая информационная модель), включая в нее представление объектов управления в средах администрирования на базе Windows. В состав интерфейса WMI, помимо расширения модели CIM, включены управляемые объекты, определенные этой моделью.

Интерфейс WMI состоит из трех уровней. Первый уровень – управляемая система: это может быть компьютер, жесткий диск, операционная система или процесс операционной системы.

Второй уровень – поставщик, он извлекает системную информацию из различных систем. Затем поставщик передает эту информацию (уже имеющую стандартный формат, независимо от управляемой системы) служебной программе CIMOM (Common Information Model Object Manager – диспетчер объектов общей информационной модели). Эта передача осуществляется через стандартный набор COM-интерфейсов. Диспетчер CIMOM может быть охарактеризован как брокер запросов. Служебная программа CIMOM и ее база данных представлены в системе службой WinMgmt.

Третий уровень интерфейса WMI – потребитель WMI, представляющий собой управляющее приложение – например, оснастку консоли MMC, сервер SMS (Microsoft Systems Management Server), приложение, созданное вами с помощью средств Visual Studio, или сценарий.

Архитектуру интерфейса WMI иллюстрирует следующий рисунок.

Рис. 8. Архитектура интерфейса WMI

В состав сервера Exchange 2000 Server включены следующие поставщики WMI:

· ExchangeQueueProvider;

· ExchangeRoutingTableProvider;

· ExchangeClusterProvider.

Эти поставщики содержат следующие классы данных, которые можно использовать для сбора информации о состоянии тех или иных служб Exchange:

· ExchangeLink;

· ExchangeQueue;

· ExchangeConnectorState;

· ExchangeServerState;

· ExchangeClusterResource.

Система Windows 2000 предлагает ряд других поставщиков WMI; их также можно использовать в Exchange 2000. Ниже перечислены поставщики WMI в составе системы Windows 2000, которые могут пригодиться разработчикам приложений Exchange 2000:

· Event Log Provider (поставщик журнала событий);

· Performance Monitor Provider (поставщик системного монитора);

· Registry Event Provider (поставщик событий реестра);

· Windows Installer Provider (поставщик службы Windows Installer);

· Registry Provider (поставщик реестра);

· Security Provider (поставщик системы безопасности);

· Simple Network Management Protocol Provider (поставщик протокола SNMP);

· Windows Driver Model Provider (поставщик модели WDM);

· Win32® Provider (поставщик Win32);

· Directory Services Provider (поставщик служб каталогов);

· Performance Counters Provider (поставщик счетчиков производительности);

· Power Management Provider (поставщик управления электропитанием);

· View Provider (поставщик представлений).

Примеры сценариев мониторинга системы Exchange 2000, использующих интерфейс WMI приводятся в документе Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков). Подробнее об инструментарии WMI см. материалы комплекта WMI SDK, которые включены в комплект Platform SDK, доступный по адресу http://msdn.microsoft.com/downloads/sdks/platform/platform.asp

Управление операциями

В данном разделе подробно описываются механизмы управления, доступные на консоли MMC. Корпорация Майкрософт активно сотрудничает со многими независимыми производителями, выпускающими универсальные решения для ASP-поставщиков. Подробнее об управлении работой системы с помощью средств, разработанных корпорацией Майкрософт, говорится в документации по Exchange 2000, материалах комплекта SDK и веб-страницы, расположенной по адресу http://www.microsoft.com/management.

Интерфейс CDO для Windows 2000

Интерфейс CDO (Collaboration Data Objects – объекты данных для совместной работы) для Windows 2000 (иногда называемый – CDO 2.0 или CDOSYS.DLL) представляет собой объектную модель для разработки приложений передачи сообщений на базе системы Windows 2000. Эта модель строится на основе стандартов SMTP (Simple Mail Transport Protocol) и NNTP (Network News Transfer Protocol) и доступна в качестве системного компонента системы Windows 2000 Server. CDO для Windows 2000 – стандартный API-интерфейс для создания программ доставки больших объемов почты или создания веб-приложений передачи сообщений, работающих в среде Windows 2000 Server.

С помощью интерфейса CDO для Windows 2000 можно конструировать компоненты двух типов.

· Приложения передачи сообщений, которые могут доставлять электронную почту с использованием протоколов SMTP и NNTP. Это могут быть обычные текстовые сообщения или же сообщения формата MIME (Multipurpose Internet Mail Extensions – многоцелевые расширения почты Интернета).

· Приемники событий транспорта, которые могут синхронно перехватывать сообщения, поступающие в локальную службу SMTP или NNTP, и изучать их содержимое и поля конверта.

Интерфейс CDO для Windows 2000 позволяет реализовать следующие функциональные возможности:

· создание и отправка сообщений с использованием протоколов SMTP и NNTP;

· вложение уведомлений и других примечаний в электронную почту, посылаемую через ваш сервер;

· создание приложений ASP (Active Server Pages), поддерживающих передачу сообщений;

· обнаружение и ликвидация ненужной почты;

· обнаружение и ликвидация ненужных сообщений групп новостей;

· проверка входящих сообщений на вирусы;

· автоматическая пересылка и фильтрация сообщений.

Интерфейс CDO для Exchange Server

При установке Exchange 2000 на компьютере, работающем под управлением системы Windows 2000, компонент CDO для Windows 2000 заменяется новым компонентом модели COM – интерфейсом CDO для Exchange 2000. Функциональные возможности интерфейса CDO для Windows 2000 образуют подмножество функционального диапазона интерфейса CDO для Exchange 2000, поэтому все компоненты, включая приемники событий транспорта, продолжат работу в обычном режиме. При установке Exchange 2000 компонент CDO для Windows 2000 выводится из системы и рабочей среды COM с отменой регистрации.

Компоненты CDO для Windows 2000 и CDO для Exchange используют общий набор значений GUID (Globally unique identifier – глобальный уникальный идентификатор), определений интерфейса, результатов перечисления, констант модулей и т.п.; поэтому при установке Exchange 2000 вам не нужно будет повторно компилировать приложение, написанное на языке Visual Basic, Visual C++ или Visual J++®. Приложение просто загрузит новый компонент CDO для Exchange 2000 на этапе выполнения.

Примечание. Если приложение, использующее компонент CDO для Windows 2000, пользуется папкой сбора входящих сообщений, устанавливаемой на компьютере службой SMTP или NNTP, то это приложение нужно будет соответствующим образом переделать. После установки Exchange 2000 местом хранения входящих сообщений почты и файлов NNTP, размещаемых на сервере, будет система Exchange Web Storage System, и папка отброшенных сообщений, которая была создана в файловой системе для служб SMTP и NNTP, становится ненужной.

Интерфейс CDO для управления средой Exchange

Интерфейс CDOEXM (CDO for Exchange Management) для управления средой Exchange позволяет программным способом управлять информацией, хранящейся на сервере Exchange 2000 Server. Компонент CDOEXM реализует решение задач администрирования среды Exchange, что дает возможность должным образом управлять и содержимым службы Active Directory, и данными Exchange. Пользователю больше не нужно работать на слишком детализированном уровне службы Active Directory, используя интерфейс ADSI.

Компонент CDOEXM включает два интерфейса:

· ImailRecipient;

· ImailboxStore.

С помощью этих интерфейсов системные администраторы могут управлять пользователями, группами и контактами.

В состав CDOEXM входят также пять автономных COM-объектов:

· FolderTree;

· PublicStoreDB;

· MailboxStoreDB;

· StorageGroup;

· ExchangeServer.

Подробнее об интерфейсе CDOEXM см. материалы комплекта Exchange 2000 SDK или веб-страницу http://msdn.microsoft.com/library/techart/cdo_roadmap.htm.

CDOEXM и ADSI

С помощью интерфейса ADSI можно выполнять многие задачи настройки службы Active Directory, однако ADSI – это API-интерфейс общего вида, и в нем нет специфических функций управления данными Exchange в службе Active Directory. Кроме того, интерфейс ADSI не обеспечивает доступа к данным на компьютере, на котором выполняется Exchange 2000.

Вместе с интерфейсом ADSI можно использовать объекты CDO. Чтобы создать пользователя в среде Exchange, достаточно сначала создать его в службе Active Directory, используя для этого интерфейс ADSI. Затем можно переключиться в интерфейс CDOEXM и создать в хранилище почтовый ящик пользователя. Когда компонент CDOEXM создает почтовый ящик, он автоматически задает на сервере Exchange 2000 свойства, связывающие почтовый ящик Exchange с пользователем, зарегистрированным в службе Active Directory.

Примеры сценариев управления системой Exchange 2000 с помощью средств CDOEXM приводятся в документе Exchange 2000 ASP Deployment Guide (Руководство по развертыванию Exchange 2000 на серверах ASP-поставщиков)».

Транспортные события

Службы SMTP и NNTP системы Windows 2000 реализуют архитектуру, допускающую добавление видоизменяемых обработчиков транспортных событий. Транспортное событие имеет место, когда сообщение в каком-либо виде передается в эти службы или из них. Простейший пример транспортного события – поступление сообщения в службу SMTP через сеть или через папку сбора входящих сообщений SMTP.

Когда происходит транспортное событие, источник этого вызывает обработчик транспортного события, каждый из которых может предпринять некие действия в зависимости от типа данных, содержащихся в сообщении. Термин «синхронное событие» означает, что источник события не выполняет никаких операций над содержимым сообщения после его передачи в обработчик и до возвращения из обработчика. Иными словами, источник блокируется на время работы обработчика. Пока обработчик событий работает, он наделяется эксклюзивными правами управления содержимым сообщения и его состоянием.

Используя интерфейс CDO и транспортных событий, вы сможете синхронно перехватывать почту или сообщения групп новостей после того, как они будут получены службой SMTP или NNTP, но до того, как они будут сохранены или ретранслированы в последующие службы.

Механизм транспортных событий позволяет делать следующее:

· проверять сообщения на вирусы;

· перенаправлять сообщение, изменяя его первоначальный путь доставки;

· блокировать прием нежелательной почты от конкретных отправителей;

· создавать специализированные службы типа автоответчика;

· архивировать сообщения;

· создавать службы списков рассылки;

· ограничивать число получателей, которым разрешается принимать входящую почту, в зависимости от домена отправителя и других атрибутов;

· помещать в группы новостей сообщения, доставляемые по протоколу SMTP;

· использовать протокол SMTP для отправки сообщений, поступающих по протоколу NNTP.

События службы SMTP

Событие службы SMTP – это проявление любой активности в рамках службы, например, отправка или поступление команды по протоколу SMTP, или передача сообщения по протоколу SMTP. При наступлении события служба SMTP, используя диспетчер событий, оповещает зарегистрированные обработчики событий о данном событии. Уведомление обработчиков событий осуществляется путем передачи информации в виде ссылок на COM-объекты.

События службы SMTP распадаются на две основные категории.

· События, которые происходят, когда команды SMTP принимаются или передаются по сети. Такие события возникают в следующих случаях:

o SMTP-клиент или агент MUA (Messaging User Agent) передает сообщения для доставки в локальную службу по протоколу SMTP;

o служба SMTP ретранслирует сообщения в другие службы SMTP.

· События, которые имеют место, когда служба получает сообщение, прошедшее через базовый транспорт SMTP. Когда сообщение проходит через транспорт, оно классифицируется (подвергается анализу и причисляется к определенной категории) и затем либо доставляется в локальное хранилище, либо ретранслируется по другому месту назначения, если оказывается не локальным.

Использование событий SMTP

События протокола SMTP и транспортные события позволяют совершенствовать и расширять функциональные возможности службы SMTP. Например, с помощью механизма событий службы SMTP можно создавать высокопроизводительные приложения, которые выполняют следующие функции:

· изменяют или расширяют набор команд протокола, поддерживаемых службой;

· изучают сообщение на предмет неправильного форматирования или небезопасного содержимого и блокируют передачу или доставку нежелательного сообщения;

· реализуют особые алгоритмы классификации сообщений, включая определение адресов ретрансляции или доставки сообщений и расширение списков рассылки;

· устанавливают собственное хранилище для доставки локальных сообщений, отличное от папки сбора входящих сообщений службы SMTP, используемой по умолчанию;

· совершенствуют и расширяют логику маршрутизации службы SMTP, чтобы на основе этой логики можно было определять, куда данная служба должна подключаться для ретрансляции сообщения, не отнесенного к категории локальной доставки.

События системы Web Storage System

События системы Web Storage System (система веб-хранения) происходят, когда сохраняются или удаляются элементы этой системы, когда начинает или заканчивает работу хранилище информации, или когда истекает определенный интервал времени. Вы можете зарегистрироваться для получения уведомлений об этих событиях и создать классы обработчиков COM-событий, которые будут получать данные уведомления. Классы обработчиков событий будут также программным образом отвечать на полученные уведомления. Среда Exchange определяет интерфейсы и методы классов обработчиков, соответствующие таким событиям, и вы можете реализовать эти интерфейсы в своих обработчиках для получения уведомлений о событиях.

Перечислим типичные приложения, использующие обработчики событий.

· Приложения управления документооборотом. Вы можете подписаться на получение уведомления о событии в случае, когда какой-либо элемент процесса документооборота помещается в систему Web Storage System. О каждом таком случае будет извещаться приемник событий, чтобы этот элемент можно было обрабатывать программным способом по мере его прохождения по инстанциям.

· Проверка достоверности элемента. Обработчики событий могут проверять элементы, когда они сохраняются в системе Web Storage System. Например, разработанный вами класс обработчиков может реализовывать обработку уведомлений об удалении, применяя некий специальный критерий, позволяющий проверить, имеет ли данный пользователь право удалить этот элемент. Или же в случае сохранения элемента класс обработчиков будет способен проверять его формат.

· Сопровождение системы Web Storage System. Когда из какого-либо конкретного места в системе Web Storage System удаляется элемент, может понадобиться изменить или удалить другие элементы, находящиеся вне системы Web Storage System. Вы можете создавать обработчики событий, автоматически выполняющие эту задачу.

Подробнее об обработчиках событий и о том, как подписаться на события, см. документацию комплекта Exchange 2000 Server SDK.

Предоставление услуг

В данном разделе описываются административные службы, которые вы можете предоставлять своим клиентам, и приводится краткий обзор методов реализации этих служб.

Предоставление услуг

Если вы обслуживаете несколько компаний или виртуальных организаций в рамках одного экземпляра службы Active Directory, то требуется создать базовую структуру предоставления услуг. Новый клиент должен иметь возможность автоматически подписываться на услуги и подписывать своих новых пользователей, не беспокоясь о настройке консоли управления MMC, службы Active Directory или параметров безопасности.

Система предоставления услуг состоит из нескольких блоков. Среди них основным является обработчик системы предоставления услуг, снабженный COM-интерфейсом, принимающим данные формата XML, HTTP и DAV (Distributed Authoring and Versioning).

Обработчик системы предоставления услуг может функционировать как отдельный модуль, например, когда информация поступает непосредственно от конечных пользователей через веб-страницу. Он может работать в конфигурации «главный-подчиненный»; например, главным элементом может быть система выставления счетов, отправляющая данные о подписке обработчику системы предоставления услуг, а сам обработчик будет играть роль подчиненного узла.

Обработчик системы предоставления услуг взаимодействует с объектом настройки. Объект настройки представляет собой интерфейс для работы с некоторой системой, такой как служба Active Directory или Exchange 2000. Вы можете также создавать свои объекты настройки для собственной базы данных или службы выставления счетов.

Связь между обработчиком системы предоставления услуг и объектом настройки осуществляется в виде транзакций с помощью службы транзакций MTS (Microsoft Transaction Services). Благодаря этому в случае какой-либо ошибки можно будет произвести откат транзакции. Объекты настройки службы Active Directory и Exchange 2000 взаимодействуют с их службами через интерфейсы ADSI и CDOEXM.

На этой схеме показано схематическое изображение системы предоставления услуг.

Рис. 9. Система предоставления услуг

Для передачи информации в службу Active Directory объект настройки этой службы использует следующие команды интерфейсов ADSI и CDOEXM:

v CreateOrganization;

v DeleteOrganization;

v CreateUser;

v DeleteUser;

v CreateDistributionList;

v DeleteDistributionList;

v EnableUser;

v DisableUser;

v AddUserToGroup;

v RemoveUserFromGroup;

v ChangePassword;

v ListAllFromGroup;

v GetProperties;

v SetProperties;

v CreateContact;

v DeleteContact;

v ResetPassword;

v LookupOrgFromTrustee;

v LookupOrgFromUPN.

Для передачи информации на сервер Exchange объект настройки сервера Exchange использует следующие команды интерфейсов ADSI и CDOEXM:

v CreateOrganization/DeleteOrganization;

v DisableMailBox;

v EnableMailBox;

v CreateMailBox;

v DeleteMailBox;

v SetDefaultMailBoxSize;

v GetMailBoxSize;

v MoveMailBox.

Если вы создаете свою собственную систему предоставления услуг, вы должны включить эти команды в базовые интерфейсы компонентов ADSI и CDOEXM.

В базе данных Microsoft SQL Server™ ведется журнал аудита, в котором хранится протокол выполнения всех транзакций, проходящих через обработчик системы предоставления услуг. В этот журнал включаются результаты каждой транзакции (успешное завершение или сбой, а также причина сбоя), коды ошибок и сообщения.

Все службы ведут журналы событий. Если вы создаете свои объекты настройки, то должны также обеспечить занесение всех событий в журнал. Можно настроить систему на запись событий в журнал, однако лучше представлять эти события в виде событий поставщика WMI. В таком случае создается служба, которая подписывается на события WMI, собирает их и сохраняет в базе данных сервера SQL Server. В результате вы получаете возможность проводить анализ использования служб; к тому же на этой основе можно создать интерфейс для работы с системой выставления счетов.

Примечание. В настоящее время корпорация Майкрософт работает над описанной структурой и планирует закончить работы в конце 2000 г.

Биллинг

Вам как ASP-поставщику нужно каким-то образом организовать взимание платы с клиентов за предоставляемые услуги. Для этого необходимо составить план обслуживания, в котором описываются предлагаемые услуги и указывается их стоимость. Затем необходимо организовать мониторинг и ведение журнала для каждой службы. Корпорация Майкрософт не выпускает программное обеспечение для службы выставления счетов, но она предлагает фундамент, на базе которого вы можете сами создавать соответствующие программные средства. В данном разделе рассказывается в общих чертах, как может работать подобная система выставления счетов. За более подробной информацией о создании системы выставления счетов обращайтесь в фирму, разрабатывающую такое программное обеспечение.

Каждое действие, добавление или удаление, осуществляемое с помощью обработчика системы предоставления услуг, порождает события, которые могут быть занесены в журнал событий сервера Windows 2000 Server. В этот журнал записываются и другие события, связанные с пользователями, виртуальными организациями и службами. Эти записи можно использовать при выставлении счетов.

Типичным примером инструмента, применяемого для выставления счетов, является квота на почтовый ящик. Когда пользователь превысит лимит размера своего почтового ящика, генерируется предупреждение, которое вносится в журнал событий. Это событие порождает сообщение, автоматически выдаваемое пользователю и системе выставления счетов; в нем пользователю предлагается возможность увеличить размер его почтового ящика.

При добавлении новой компании или нового пользователя объект настройки помещает все записи в службу Active Directory и систему Exchange 2000. Вы (или независимый производитель программ выставления счетов) можете построить свой объект настройки, записывающий в базу данных дополнительные сведения, которые понадобятся для выставления счета. Графическое представление этого механизма приводилось в предыдущем разделе настоящего документа.

Информация, используемая в системе выставления счетов, должна собираться из различных файлов журналов, доступных через службу WMI. В частности, должен учитываться журнал событий сервера Windows 2000 Server или журнал службы IIS системы Windows 2000. Можно также привлекать события системы Web Storage System, события протокола или события транспорта; это позволит выполнять определенные действия в зависимости от режима использования служб.

При создании специальных служб выставления счетов на основе транзакций убедитесь, что все транзакции регистрируются, по крайней мере, в журнале событий сервера Windows 2000 Server. Но лучшим решением является предоставление всей информации через поставщика WMI. Это позволит другой службе подписаться на услуги поставщика и использовать данную информацию для иных целей.

Служба выставления счетов должна подписаться на доступ к различным поставщикам WMI (и системным, и собственным) и собирать всю информацию в базу данных счетов. Как уже отмечалось, такую базу данных можно использовать и для анализа режима использования служб.

Совместная работа в режиме реального времени

Пользователи должны иметь возможность взаимодействовать друг с другом в режиме реального времени, где бы они ни находились. Они должны иметь возможность участвовать в групповых обсуждениях и совместных проектах, работать с общими файлами, вести конфиденциальные беседы независимо от своего местонахождения. Вы можете предоставить своим клиентам такие услуги; для этого используются следующие службы совместной работы, поддерживаемые в Exchange 2000:

v Instant Messaging (служба немедленной передачи сообщений);

v Chat Service (служба разговоров);

v Conferencing Service (служба конференций).

Эти службы подробно описываются в последующих разделах.

Служба немедленной передачи сообщений

С помощью службы немедленной передачи сообщений (Instant Messaging) пользователи могут вести конфиденциальную беседу «один на один» и подписываться на информацию о присутствии своих корреспондентов. Информация о присутствии содержит сведения о состоянии: Online (работает в сети), Invisible (невидим), Busy (занят), Be Right Back (сейчас вернется), Away (отсутствует), On the Phone (говорит по телефону), Out to Lunch (на обеде) или Appear Offline (работает автономно). Если пользовать подписан на информацию о присутствии другого пользователя, то при изменении состояния последнего он будет тут же оповещен об этом факте.

Служба немедленной передачи сообщений, в отличие от обычной электронной почты, не сохраняет копии сообщений в системе. Когда вы завершаете сеанс немедленной передачи сообщений, эти сообщения теряются.

В состав службы немедленной передачи сообщений входит три фундаментальных элемента:

v домен немедленной передачи сообщений – логическая совокупность пользователей и серверов, представленная виртуальным сервером;

v домашний сервер немедленной передачи сообщений – виртуальный сервер, на котором размещаются учетные записи пользователей данной службы, а также хранится информация о присутствии;

v маршрутизатор немедленной передачи сообщений – принимает сообщения и выбирает для них маршрут к соответствующему домашнему серверу.

Служба немедленной передачи сообщений работает на сервере IIS (Microsoft Internet Information Services – информационные службы Интернета) в качестве подключаемой библиотеки ISAPI (Internet Server Application Programming Interface). Все атрибуты пользователей и данные, необходимые для проверки подлинности, предоставляются службой Active Directory. Информация о присутствии хранится в базе данных узла, которая также играет роль модуля ESE (Extensible Storage Engine – расширяемый модуль обработки хранилищ данных). Связь между службой IIS, базой данных узла и службой Active Directory реализуется на уровне серверного приложения. Связь между клиентом и сервером поддерживается средствами протокола RVP (Rendezvous protocol), представляющего собой расширение протокола HTTP-DAV (HTTP-Distributed Authoring and Versioning). Архитектура системы немедленной передачи сообщений представлена на следующей схеме.

Рис 10. Архитектура системы немедленной передачи сообщений

FTM (Firewall Topology Module – модуль топологии брандмауэра) представляет собой службу сервера немедленной передачи сообщений, в которой хранится информация о каждом таком сервере, независимо от того, по какую сторону брандмауэра он находится. Кроме того, службой FTM сохраняются сведения о том, как можно проникнуть через брандмауэр. Служба FTM содержит данные, которые определяют, может ли данный IP-адрес источника подключиться к данному IP-адресу назначения и требуется ли прокси-сервер. Прокси-сервер – это сервер немедленной передачи сообщений, расположенный между брандмауэром и домашним сервером или сервером маршрутизации.

Идентификация всех пользователей службы немедленной передачи сообщений осуществляется при помощи уникальных URL-адресов. Каждому пользователю назначаются два URL-адреса: адрес домашнего сервера и адрес домена, указывающий на маршрутизатор немедленной передачи сообщений. Вместо URL-адреса можно использовать имя пользователя службы немедленной передачи сообщений, формат которого вы можете установить в виде user@im_domain. Чтобы такими именами можно было пользоваться, вы должны зарегистрировать все домены немедленной передачи сообщений в системе DNS (Domain name system – система доменных имен).

Масштабирование службы немедленной передачи сообщений

Один домашний сервер немедленной передачи сообщений может обслуживать до 10 000 одновременных подключений, а один маршрутизатор немедленной передачи сообщений – до 20 000 одновременных подключений. Подключение означает, что пользователь запустил на клиентском компьютере службу немедленной передачи сообщений.

В секторе индивидуальных пользователей служба немедленной передачи сообщений применяется иначе, чем в сфере бизнеса. Типичный бизнес-пользователь проводит в подключенном режиме в среднем 80% рабочего времени, тогда как обычный пользователь – лишь 5–10% времени.

Клиенты подключаются к маршрутизаторам немедленной передачи сообщений, которые ретранслируют входящие запросы на соответствующий домашний сервер. На следующем рисунке показана топология развернутой системы немедленной передачи сообщений.

Рис. 11. Топология немедленной передачи сообщений

Подробнее о службе немедленной передачи сообщений см. раздел Instant Messaging (Немедленная передача сообщений) в документации по серверу Exchange 2000 Server.

Служба разговоров

С помощью службы разговоров (Chat Service) пользователи могут обсуждать различные темы в форумах со связью типа «один-ко-многим» (эти форумы также называют каналами или комнатами). Комнаты организованы в виде виртуальных сообществ, в каждом из которых затрагивается свой круг тем.

Служба разговоров Exchange 2000 интегрирована в систему Windows 2000 и использует следующие ее средства:

v службу каталогов Active Directory;

v средства безопасности Windows 2000;

v службы кластеризации.

Для установки службы разговоров в среде размещения на сервере ASP-поставщика необходимо сначала оценить размеры обслуживаемых компаний. Типичный сервер разговоров может поддерживать одновременно до 20 000 пользователей из разных сообществ. Если у ваших заказчиков приблизительно такое количество пользователей, вам следует установить службу разговоров на компьютере с четырьмя процессорами и оперативной памятью объемом 512 МБ.

Если организации, являющиеся вашими заказчиками, имеют небольшие размеры, можно для каждой из них создать свое сообщество. С помощью службы Active Directory можно проводить проверку подлинности пользователей и формировать списки управления доступом для каждого сообщества так, чтобы оно было скрыто от других компаний. Например, предположим, что к вашему серверу разговоров подключается пользователь JohnB@companyA.com. Поскольку для всех сообществ действуют таблицы управления доступом (ACL), JohnB сможет видеть лишь каналы, выделенные для компании CompanyA.com.

Если среди ваших клиентов есть крупная компания, вы можете установить выделенный сервер разговоров, который будет обслуживать сообщества, относящиеся только к этой компании. Присвойте серверу подходящее имя, назначьте ему запись DNS и правильно установите параметры безопасности. О том, как это делать, см. раздел Instant Messaging (Немедленная передача сообщений) в документации по серверу Exchange 2000 Server. На следующем рисунке показана схема развертывания службы разговоров, в которой выделены серверы для конкретных организаций.

Рис. 12. Размещение службы разговоров на выделенных серверах

Несколько служб разговоров могут размещаться на одном сервере ASP-поставщика, но с точки зрения подключенного пользователя они выглядят как несколько автономных серверов. Вы настраиваете параметры и систему безопасности отдельно для каждого сообщества, что позволяет оказывать услуги по сопровождению и проводить индивидуальное развертывание.

Служба разговоров Exchange 2000 интегрирована со службой безопасности системы Windows, и поэтому к сообществам и зарегистрированным каналам (комнатам) можно применять списки управления доступом (ACL). Для проверки подлинности можно использовать любой интерфейс SSPI (Security Service Provider Interface – интерфейс поставщика служб безопасности), при условии, что его поддерживает клиент службы разговоров; в частности, могут использоваться поставщики независимых производителей и самих заказчиков. К числу дополнительных средств управления безопасностью относятся запреты на присутствие и классы участников, с помощью которых можно, используя протокол разговоров, контролировать и ограничивать доступ и возможности пользователей.

Служба разговоров Exchange 2000 также поддерживает модель Server Extensibility (расширяемость сервера), которая подробно описывается в материалах комплекта Microsoft Platform SDK. На основе этой модели вы можете разрабатывать собственные расширения, которые позволяют наблюдать за событиями, происходящими в службе разговоров, и реагировать на них.

Можно создавать расширения, поддерживающие модель COM, на языках Microsoft Visual Basic, Visual C++ и др. С помощью соответствующего API-интерфейса расширения могут реагировать на события, связанные с серверами, пользователями и каналами, – и локально, и в сети разговоров. Вдобавок к возможностям расширения API-интерфейса, объектная модель сервера разговоров (Chat Server Object Model) обеспечивает широкий спектр услуг доступа к каналам и пользователям, зарегистрированным на сервере. Наконец, объектная модель администрирования службы разговоров (Chat Service Administration object model) позволяет настраивать саму службу разговоров.

Вы можете использовать расширения для создания собственных моделей входа, а те, в свою очередь, – для анализа использования служб и выставления счетов.

Как и в предыдущих выпусках, служба разговоров использует в качестве основного инструмента наблюдения за рабочими характеристиками счетчики производительности Windows. Служба разговоров поддерживает также несколько собственных счетчиков. Счетчики службы разговоров предоставляют информацию о самой службе, например, общее число клиентских подключений, серверных операций, поставленных в очередь, и активных рабочих потоков. Счетчики сообществ разговоров позволяют изучать отдельные экземпляры сообщества: например, они показывают число анонимных клиентов, число клиентов, прошедших проверку достоверности, число подсоединений к каналу, число полученных или отправленных байтов. Подробнее о событиях службы разговоров Exchange и счетчиках системного монитора см. в документации комплекта Platform SDK.

Службы конференций

Сервер Exchange 2000 Conferencing Server дает пользователям возможность проводить виртуальные встречи. На клиентской стороне пользователю предоставляются такие мультимедийные услуги, как аудио- и видеосвязь, передача файлов, разговоры и общая доска. Пользователи могут планировать интерактивные встречи и резервировать необходимые для них ресурсы с помощью приложения Microsoft Outlook 2000. Клиентский компьютер использует протокол T.120, интегрированный в такие продукты, как программа проведения конференций Microsoft NetMeeting®.

Сервер Exchange 2000 построен на базе архитектуры CTP (Conference Technology Provider – поставщик технологии конференций). В комплект Exchange 2000 включены два CTP-поставщика: один для многоадресных аудио- и видеоконференций и один для информационных конференций. При обслуживании конференций сервер Exchange 2000 выступает в роли сервера информационных конференций с полной поддержкой протокола T.120 и способен поддерживать аудио- и видеопотоки многоадресной передачи по протоколу IP.

Многоточечные информационные конференции поддерживают следующие возможности.

v Совместное использование приложений. Пользователь может предоставить в общее пользование другим участникам конференции программу, работающую на его компьютере, например, Microsoft Word. Участники конференции смогут одновременно просматривать одну и ту же информацию и наблюдать за действиями, которые выполняет в документе пользователь, предоставивший приложение в общий доступ.

v Передача файлов. Участник конференции может отправить файл другому участнику или всем остальным участникам. Передача файла происходит в фоновом режиме, так что все могут продолжать работать в приложении, пользоваться доской или вести разговор.

v Доска. С помощью этого многостраничного многопользовательского приложения для рисования участники конференции могут чертить схемы и отображать другую графическую информацию.

v Разговоры. Пользователь может вводить текстовые сообщения, адресованные другим участникам конференции, а также вести заметки по ходу встречи и записывать выполняемые действия.

Основное различие между решением одноранговой конференц-связи, подобным NetMeeting, и серверным решением, таким как Exchange 2000, заключается в том, что во втором случае весь сеанс связи проходит централизованно на сервере. При использовании NetMeeting «хозяином» конференции становится инициировавший ее клиент, и когда он выходит из конференции, она завершается.

Сервер использует многоадресную передачу по протоколу IP; эта эффективная технология связи типа «один-ко-многим» создает связующее дерево, в котором любые два маршрутизатора связаны между собой только одним путем. Клиент регистрируется (подписывается) на маршрутизаторе многоадресной передачи. Многоадресную IP‑передачу следует отличать от широковещательной рассылки, когда информация отправляется каждому клиенту, подключенному к сети.

В качестве транспорта многоадресной IP-передачи используется протокол RTP (Real-Time Transport Protocol), который предусматривает использование стандартного мультимедийного заголовка, включающего штамп времени, порядковый номер пакета и информацию о формате полезных данных.

Exchange 2000 устанавливает две службы Windows 2000 для проведения конференций:

v Exchange Conferencing Service (служба конференций Exchange) – компонент службы конференций, отвечающий за планирование и резервирование, называемый также Conference Management Service (служба управления конференциями);

v модуль Exchange T.120 MCU (Multi-point control unit – блок управления многоточечной связью) – среда проведения сеансов конференций в стандарте T.120.

Компоненты сервера Exchange 2000 Conferencing Server показаны на следующем рисунке.

Рис. 13. Сервер Exchange 2000 Conference Server

Система Windows 2000 поддерживает информационные конференции Exchange с использованием следующих служб:

v Active Directory;

v IIS;

v сервер DHCP (Dynamic Host Configuration Protocol) с поддержкой расширенной многоадресной передачи;

v QoS (Quality of Service – качество обслуживания).

Сервер DHCP с поддержкой расширенной многоадресной передачи

Чтобы вести многоадресную передачу, сервер должен иметь адрес для многоадресных IP-конференций. Такие адреса предоставляет протокол MADCAP (Multicast Address Dynamic Client Allocation Protocol). MADCAP – это расширение службы DHCP, входящее в комплект поставки этой службы, но независимое от нее. Службы MADCAP могут работать на одном сервере, а служба DHCP – на другом.

Сервер, на котором работает служба управления конференциями и, следовательно, CTP-поставщик службы видеоконференций, должны иметь сетевое подключение к серверу Windows 2000 Server с установленной службой MADCAP . Последнюю можно запустить независимо от любых имеющихся служб DHCP, но устанавливается она с помощью службы DHCP.

QoS

Обычный трафик данных основан на передаче по протоколу IP без установки подключений, причем этот протокол не гарантирует доставку каждого пакета. Приложения реального времени, в частности, мультимедийные приложения, работают в зависимости от доступности сети и ее пропускной способности; в связи с этим возникает необходимость в поддержании качества обслуживания (QoS). В системе Windows 2000 поддержка QoS реализована с помощью ряда компонентов, которые могут взаимодействовать друг с другом; в частности, предлагаются следующие возможности:

v поддержка мультимедийных приложений, работающих в режиме реального времени;

v гарантия своевременной передачи больших массивов данных;

v возможность совместного использования сети в режиме, исключающем дефицит пропускной способности, предоставляемой приложениям.

Сервер конференций в центре данных

При развертывании крупномасштабной системы Exchange 2000 Conferencing Server необходимо установить выделенные серверы для каждой службы. Число требуемых модулей T.120 MCU зависит от профиля использования служб. На следующем рисунке показана схема развертывания сервера конференций, включающая службу управления конференциями и два модуля T.120 MCU.

Рис. 14. Развертывание сервера Exchange Conferencing Server со службой управления конференциями и двумя модулями MCU

Между использованием сервера конференций внутри корпорации и для услуг хостинга, реализуемой ASP-поставщиком, существуют четкие различия. В корпоративной среде каналы связи между клиентами и сервером не проходят через брандмауэр и Интернет. Хостинг сервера конференций реализовать труднее, поскольку служба управления конференциями и модули MCU находятся за брандмауэром, и пользователи должны обращаться к серверу конференций через этот брандмауэр.

Задача еще более усложняется, когда клиент находится в организации и для доступа в Интернет должен проникнуть через ее внутренний брандмауэр. В этом случае клиент, осуществляющий доступ к серверу конференций, вынужден преодолевать два брандмауэра.

Служба видеоконференций

Служба видеоконференций создает источник событий, из которого выдаются сообщения об ошибках. Эти события должны генерироваться для всех сбоев, прерывающих работу действующих служб. В дальнейшем после ликвидации сбоя генерируется еще одно событие, сигнализирующее о восстановлении работы.

В службе видеоконференций реализованы следующие счетчики производительности:

v Active Conferences – число активных конференций;

v Join Requests – число запросов на подсоединение;

v Active MADCAP – описание области, обслуживавшей адрес многоадресной передачи последней;

v Active ILS – имя сервера ILS (Internet Locator Service – служба локатора Интернета), на котором публикуются общедоступные конференции;

v ILS Publish Errors – число конференций, которые не удалось опубликовать на сервере ILS;

v Public Conferences – число активных общедоступных конференций;

v Private Conferences – число активных частных конференций;

v Join Request Denied – число запросов на подсоединение, отклоненных из-за того, что число участников уже достигло максимально допустимого предела.

Журналы

Служба управления конференциями создает журнал событий, в котором регистрируются некоторые виды операций. Конфигурация, фиксирующая такие события, определяется на странице свойств службы управления конференциями. Каждое событие записывается в файл типа CSV, именем которого служит дата генерации файла, как это делается для файлов журналов IIS.

Используя эти файлы, вы можете изучать операции сервера конференций в целях выставления счетов, анализа использования служб и т.п.